The present invention relates to compression of payload carried in data packets, e.g., IP (Internet Protocol) packets and/or UDP and TCP packets. The purpose of such compression is to reduce IP traffic throughput, especially over bandwidth limited links (e.g. air interface, radio links).
The compression/decompression can be performed either a) end-to-end, or b) only on a segment of the packet traversal path that has limited bandwidth. For example, the compression can be performed in a router and/or central network elements like GGSN (Gateway GPRS Supporting Node, GPRS=General Packet Radio Service) or SGSN (Serving GPRS Supporting Node), for example.
In certain architectures, the compression is not performed end-to-end. Instead, it is applied in an intermediate node on the traversal path of IP packets. If the source or another node before the compressor already applied encryption, compression will not reduce the packet size due to the nature of encryption. Therefore, the Central Processing Unit CPU resource is simply wasted.
This may occur, for example, in the above-described architecture b) when UDP/TCP packets carry data encrypted by TLS/SSL, as described in Dierks, T. and C. Allen, “The TLS Protocol”, IETF RFC 2246, January 1999. Namely, in architecture b), a compressor may not be located at the packet source. Therefore, the compressor may receive UDP/TCP packets carrying data that has been encrypted by TLS/SSL. If it blindly compresses those packets, it will not reduce packet size and thus the CPU resource and memory resource are simply wasted.
Another example for the applied encryption is ESP (Encapsulating Security Payload) which is described in Kent, S., and R. Atkinson, “IP Encapsulating Security Payload”, RFC 2406, November 1998.
Thus, there is a problem in the prior art that compression of data packets is performed although it would not be necessary.